perm filename CBUGS[CMP,LSP] blob
sn#211948 filedate 1976-04-22 generic text, type C, neo UTF8
COMMENT ā VALID 00002 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00002 00002 (COMMENT THIS FUNCTION GETS LOSTVAR-ILOC1)
C00008 ENDMK
Cā;
(COMMENT THIS FUNCTION GETS LOSTVAR-ILOC1)
(CMP (LOSEVAR) (LAMBDA NIL ((LAMBDA (A B C D E) D) 1 2 3 4 5)))
(COMMENT THIS BUG WAS SUBMITTED BY BEATRICE FROCK OF THE ROYAL
INSTITUTE OF TECHNOLOGY DEPARTMENT FOR COMPUTER SCIENCES
NUMERICAL ANALYSIS S-10044 STOCKHOLM 70 SWEDEN STOP HER
FUNCTION FOR PRODUCES A LOSTVAR-ILOC1 WHICH APPEARS TO BE
THE VALUE OF THE (EVAL U2) STOP THE BUG SEEMS TO BE DUE TO
THE EVAL IN PREDICATE CONTEXT IN THE COND IN SIDEEFFECT
CONTEXT STOP FORSHORT PRESERVES THE BUG WHILE FORFIX CURES
IT)
(DEFPROP FOR
(LAMBDA (A U1 U2 U3)
(PROG NIL
(SETQ A 0)
NEXT (EVAL U3)
(SET A (EVAL U1))
(COND ((EVAL U2) (RETURN)) (T (GO NEXT)))))
EXPR)
(DEFPROP FORSHORT
(LAMBDA (U2) (PROG NIL (COND ((EVAL U2) (RETURN)))))
EXPR)
(DEFPROP FORFIX
(LAMBDA (U2) (PROG NIL (COND ((WASEVAL U2) (RETURN)))))
EXPR)
ā11-OCT-75 1400 L,HJS @ NBST
I am fairly sure that I know why the LISP compiler was bombing out on me. The
trouble is that inside of an INTERNAL LAMBDA expression it will not allow you to
access any location that is further away than 8 positions from the top of the
stack. I would not be surprised if this is caused by some confusion over BASE
and IBASE. I have replaced those EXPRs that would not compile by PROGs and
replaced the LAMBDA variables by PROG variables. The entire system compiles now
with a dramatic decrease in execution time. There is a file on my disk area
(MLISP) called CANBAD[L,HJS] which displays this erroneous behavior.